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SUMMARY 


Tms  project,  which  seeks  to  develop  a  group-via-computer  Interrogation 
network,  is  progressing  according  to  schedule  and  budget.  Most  of  the  first 
six  months'  effort  has  been  spent  writing  code.  Hence,  there  is  little  of  sig¬ 
nificance  to  report  at  this  early  stage  of  the  project  other  than  the  usual 
descriptions  of  program  structures  and  the  minor  problems  of  transient  interest 
common  to  any  computer  system  development. 


An  early  "bare-bones"  version  of  the  remote  conferencing  system  has  been 
implemented,  which  has  minimal  capabilities— remote  respondents  answering  ques 
tionnaires.  The  required  programs  are  being  structured  in  modular  form.  The 
addition  of  new  modules  to  be  incorporated  in  the  later  program  releases  will 
permit  more  flexibility  in  the  group-via-computer  interaction. 
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I .  INTRODUCTION 


This  is  the  first  semiannual  Technical  Report 
on  a  two-year  study  concerned  with  the  development 
network  for  policy  formulation,  it  summarizes  the 
period  from  March  6  to  September  6,  1972. 


describing  work  in  progress 
of  a  group  interrogation 
work  .completed  during  the 


objectives 

Tins  project  seeks  to  develop  a  geographically  distributed  group-via- 
computer  management  tool.  New  equipment  is  to  be  designed  and  programs  are 
to  be  written  to  automate  the  extraction  and  collation  of  expert  opinion. 

bas  dT  HhrUSt  ^  tHe  Pr‘SSent  PhaSS  ^  U’1S  Pr°jeCt  iS  t0  '«"•»*  computer 
based  techniques  for  the  rapid  extraction  and  evaluation  of  judgments  from 

geographically  dispersed  expert  participants,  but  where  full  decision-making 

power  must  be  reserved  by  a  single  executive  responsible  for  the  decision. 

This  line  of  research  and  development  is  not  entirely  new,  and  major 
e  orts  in  this  field  have  gone  before,  where  „e  hope  that  our  work  will  dif- 
er  from  earlier  efforts  is  in  that  we  seek  to  develop  a  "practical"  system 
will  be  useful  as  a  real-world,  real-time  management  tool.  The  acid  test 

o  practicality  is  whether  the  system  will  in  fact  be  employed  by  management 
m  their  day-to-day  operations. 

Within  three  months  after  the  start  of  this  project,  we  were  able  to  have 

a  simple  mock-up  demonstration.  But  a  mock-up  demonstration  and  a  real-world 

system  are,  of  course,  miles  apart-as  a  management  tool  the  system  lacks  many 

ingredients  required  to  be  a  truly  viable  system.  During  the  course  of  this 

project ,  we  seek  to  reduce  this  distance  between  today’s  state  of  the  art  and 

q  irements  of  a  practical,  usable  system,  by  new  computer  software  de- 
vplnnmpnt.q  and  nrono^d  bavd^vo  „„ 


r,r*i  atsb ir.wrfUWMeWVB  *rr  wrattl  il  a 
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RELEVANCE  TO  ARPA-IPT 

While  some  of  the  reported  activity  is  concerned  with  people-to-machina 
interaction  and  new  management  tools  and  applications,  its  emphasis,  in  line 
with  ARPA-IPT' s  specific  interest  in  the  computer  and  communications  aspects 
of  the  system,  is  on  hardware  and  associated  software  development. 

To  augment  the  work  for  ARPA-IPT  and  to  expand  its  scope  in  the  direction 
of  man-machine  interaction  and  applications  both  to  the  collection  of  judg¬ 
mental  data  and  to  computer-aided  scientific  collaboration  at  a  distance,  we 
have  received  a  three-year  grant  from  the  Office  of  Computing  Activity  of  the 
National  Science  Foundation.  The  two  projects  are  differentiated  (in  simpli¬ 
fied  terms)  in  that  the  ARPA  activity  is  directed  toward  the  development  of 
the  computer-based  system  elements  themselves,  whereas  the  work  on  behalf  of 
NSF  is  concerned  mainly  with  the  exploration  of  group  problem-solving  efforts 
with  the  aid  of  a  computer  network. 


PROJECT  STAFF 

Responsibility  for  supervision  of  specific  aspects  of  this  project  is 
divided  as  follows:  Mr.  Paul  Baran,  direction  of  the  system  design;  Dr.  Roy 
Amara,  supervisory  and  administrative  management;  and  Dr.  Olaf  Helmer,  design 
and  performance  of  experiments  on  the  system. 

The  bulk  of  the  work  on  this  project  and  the  total  programming  effort 
are  being  performed  by  Dr.  Hubert  Lipinski,  Mr.  Richard  Miller,  and  Mr.  Robert 
Randolph  of  the  Institute,  with  the  occasional  assistance  of  Mr.  John  Melvin, 
currently  at  the  RAND  Corporation,  and  Dr.  Rainer  Schulz  at  Stanford  University. 


II.  program  organization 


COMPUTER  USED 

The  Programs  are  primarily  „ritt<Jn  ,n  ^ 

rinrer  the  tenex  operatirg  syst°m-  ™s — *  -uable  to 

at  Z  bu  t  t  ln  a  "Umber  °f  inStalUti°nS-  «*  -d  the  PDP-10 

BAND  temporarily  switched  over  to  the  one  at  BBN  because  of  a  relia 
Tipcat  71  P  ““  ™  ‘hen  "  “ddreSSed  the  “»  — '  **  «*  -oal 


j 

1 

] 

j 

i 
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modules 


me  programs  are  Witten  as  a  set  of  peonages  or  modules, 
ca  led  up  as  needed  during  the  semiunprediotable  course  of  the 
via-computer  interaction. 


Modules  are 
unfolding  group- 


SPECIFICATION  of  the  modules 

The  specification  of  the  modules  derives  fvom  *  .  . 

+  ,  ■  es  r4-om  a  preliminary  analysis  oj 

the  requirements  of  a  general-nm-m00  .  .  7  Y  ls  oj 

meats  and  comments  rapidly  and  efLt  7’““  ^  jUd9’ 

remote  experts.  CtlVely  ^  3  °f  graphically 

a  hi  7  7^  ^  °Pti0"S  BVentUally  “1U  from  being  able  to  ash 

choice  L'""rea  SSt  °E  q“eSti°nS  °f  indi''ld“*l=  «  times  of  their  own 
o  running  an  open-ended  parliamentary  debate  in  real  time  Addif 
recrements  are  posed  because  of  the  new  modes  of  ZZ- 

where  ^ ^  e*amPle'  all°“S  con<3uctil'®  a  structured  conference 

e  everyone  speaks  at  the  same  time.  Programs  are  needed  to  keep  the  si¬ 
multaneous  messages  in  order.  P 

we  har  SPeCifiCati0"  °f  S°me  °f  the  modules  must  be  kept  open-ended  until 
have  experimented  with  them  and  determined  which  procedures  are  of  most 


j 


{ 


jl 


:''-v 
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value  to  the  system  users.  Thus,  the  general  plan  has  each  module  capable 
of  being  changed  or  deleted  with  minimal  repercussion  to  the  remainder  of 
the  operating  program.  Because  of  the  expectation  of  change,  we  are  using 
a  ground  rule  that  the  written  code  have  adequate  comments  interspersed  so 
that  at  least  minimal  documentation  will  survive  the  continual  programming 
changes  envisioned. 


RELEASES 

The  concept  of  module  autonomy  is  more  a  goal  than  a  reality.  In  prac¬ 
tice  it  is  difficult  to  change  one  module  without  reflecting  changes  else¬ 
where.  Therefore  we  have  adopted  the  standard  nomenclature  of  "releases" — 
grouping  individual  changes  so  that  major  changes  occur  infrequently  and  the 
user  is  always  working  with  the  last  fully  debugged  release. 

The  releases  are  described  in  Sections  III  and  IV.  We  are  currently 
operating  under  Release  2  and  programming  Release  3.  As  will  be  described, 
we  have  sufficient  mandatory  improvements  scheduled  that  will  take  us  to 
Release  5  within  the  year. 


DOCUMENTATION  STATUS 

While  documentation  for  the  program  development  exists,  it  is  primarily 
in  the  form  of  notes  and  comments  in  the  program  listings  themselves  and 
of  highly  simplified  flow  charts. 


This  documentation  is  adequate  for  the  preliminary  programming  purposes 
of  the  project  but  it  is  not  yet  suitable  for  detailed  presentation  in  this 
report  without  additional  explanation. 


As  we  have  a  sufficiently  detailed  description  of  the  operation  of  the 
programs  in  the  next  sections,  we  have  chosen  to  defer  full  documentation 
until  after  the  evolution  of  the  pregr?™  etahiliy.pq  and  to  nresent  it  in  the 


next  Technical  Report. 


III.  PROGRAM  DESCRIPTIONS 


TEAMS 

The  system  is  based  on  the  concept  of  a  management  team  (consisting  of 
a  Chairman,  an  Umpire,  and  one  or  more  Editors)  together  with  a  sizable  group 
of  expert  respondents  (called  respondents  or  experts,  interchangeably) .  Each 
person  is  assumed  to  have  his  own  terminal,  CRTs  for  the  management  team  and 
eit  “  CRTS  “  hard-c°Py  terminals  for  the  respondents,  whichever  they  may 
have  available.  (At  this  time  we  prefer  that  the  respondents'  terminals  oper¬ 
ate  at  30  characters  per  second  or  higher  to  minimize  interactive  delays  and 
that  the  terminals  be  full-duplex  ASCII.) 


DUTIES 

It  is  the  duty  of  the  expert  (respondent)  to  answer  questions  posed  to 

him.-  to  make  suggestions,  to  argue,  to  comment  on  statements  made  by  others, 

and  to  be  tree  to  introduce  motions  changing  the  procedures  or  directions  of 
the  inquiry. 

It  is  the  duty  of  the  management  team  to  keep  the  process  going  in  an 
orderly  direction. 

The  Chairman  is  the  man  with  the  problem.  He  is  the  executive  decision¬ 
maker,  who  may  be  assumed  to  have  little  understanding  of  the  computer  system. 
T  e  Chairman's  assistant  is  the  Umpire.  The  Umpire  is  the  man  traditionally 
t  ought  of  as  the  chairman  in  the  usual  parliamentary  debate.  It  is  the  duty 
o  the  Umpire  to  answer  procedural  questions,  to  carry  out  the  intent  of  the 
Chairman,  and  to  conduct  the  inquiry.  In  general,  it  is  only  the  chairman 
who  will  know  the  substantive  issues  being  discussed,  and  it  is  only  the  Um¬ 
pire  w„o  will  be  fully  acquainted  with  the  capabilities  and  limitations  cf 

eye  +-om 

It  is  the  duty  of  the  Editor (s)  to  unburden  the  Umpire  from  being  over-  ' 
loaded  by  the  upward  flow  of  simultaneous  information  from  the  respondents. 


-6- 


The  Editor  will  indicate  how  each  respondent's  input  is  to  be  treated.  For 
example,  it  may  be  an  answer  to  a  question,  or  a  motion;  if  a  motion,  then 

type  of  motion.  The  Editor  is  usually  the  man  to  whom  the  respondent  talks 
when  he  seeks  help  on  any  matter. 


management  team  mock-up 

Since  at  present  the  Institute  has  only  three  terminals  and  two  full¬ 
time  people  on  the  project,  we  have  compressed  the  range  of  duties  of  the 
Chairman,  Umpire,  and  Editor  into  a  single  hypothetical  person  at  this  stage 
of  program  development.  This  composite  role  is  called  "Chairman"  until 
these  duties  are  separated  later  in  the  program  development  cycle. 


PROGRAMS 

The  respondent  uses  a  program  called  EXPERT,  while  the  Chairman  uses  a 
program  called  CHAIRMAN.  These  are  high-level  programs  that  in  turn  call  up 
specific  modules  as  needed.  These  programs  now  comprise  about  7,500  lines 
of  source  code  including  a  repertoire  of  information  transferring,  process¬ 
ing,  and  communicating  subroutines  as  well  as  the  usual  utility  programs. 

Prior  to  the  initiation  of  an  inquiry  session,  it  is  necessary  for  the 
Chairman  to  prime  the  system  by  inserting  files  containing  text  for  background 
information  and  for  the  list  of  questions  to  be  asked.  (The  program  for 

creating  the  background  file  is  called  CBKGF ;  the  one  for  the  question  file 
is  TPROC . ) 

The  Chairman's  Program 

At  all  times,  CHAIRMAN  is  either  executing  some  command  explicitly  given 
by  the  investigator  or  else  awaiting  another  such  command.  By  means  of  these 
commands,  the  Chairman  can  call  for  various  routines  that  monitor  and  direct 
the  flow  of  the  inquiry.  These  include,  for  example: 

•  a  display  showing  which  respondents  are  on  the  system,  along  with 
their  terminal  numbers  and  other  identifying  information; 


-7- 


•  a  display  summarizing  the  progress  of  each  respondent  (or  of  the 
panel  as  a  whole)  through  a  particular  question; 

•  a  display  showing  the  current  status  of  the  inquiry  control  switches*; 
and 

•  a  routine  to  set  these  switches*  and  thus  direct  the  flow  of  the 
inquiry. 

In  addition,  the  investigator  can  call  a  variety  of  text  and  numerical 
processing  routines: 

•  a  routine  for  replying  to  requests  from  individual  respondents  for 
specialized  background  data; 

•  routines  to  search  the  indexed  files  of  input  information  for  re¬ 
sponse  "packages"  of  any  given  type,  display  these  responses  on 

the  Chairman's  terminal,  and  return  selected  responses  to  the  panel; 

•  routines  for  rephrasing  or  deleting  existing  questions  from,  and 
introducing  new  questions  into,  the  inquiry;  and 

•  routines  for  gathering,  processing,  and  displaying  (in  alternative 
formats)  respondents'  estimates  of: 

single  numerical  quantities,  and 
-  three-point  probability  distributions. 


The  Respondent' s  Program 

The  respondents  are  invited  to  join  in  the  inquiry  and  told  when  and 
how  to  tie  into  the  ARPANET  and  the  chosen  host  computer,  and  to  call  pro¬ 
gram  EXPERT . 

Each  respondent  is  given  his  own  copy  of  program  EXPERT.  This  program 
leads  the  respondent  through  the  inquiry.  Thus,  the  inquiry  consists  of  a 
single  CHAIRMAN  program  and  a  number  of  simultaneously  operating  EXPERT 
programs  communicating  to  the  CHAIRMAN  program.  The  present  Release  2  of 
the  EXPERT  program  assumes  that  each  respondent  will  answer  each  question 
in  approximately  simultaneous  fashion.  (This  restriction  will  be  removed  in 
later  releases.) 


Changed  to  command  word  in  Release  3. 
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The  EXPERT  program  first  provides  the  respondent  with  background  infor¬ 
mation  and  then  carries  him  to  the  main  body  of  the  inquiry  where  he  is  called 
on  to  answer  questions  previously  posed  by  the  Chairman  in  TPROC.  In  answer¬ 
ing  each  question,  the  respondent  may  proceed  through  three  phases:  a  question 
review  phase,  an  extraction  of  verbal  statements  phase,  and  a  numerical  re¬ 
sponse  phase.  (In  Release  3,  bypassing  of  phases  is  permitted  the  respondent.) 

Input  provided  by  the  respondents  is  stored  in  indexed  files  that  can  then 
be  retrieved  by  processing  and  display  routines  at  the  choice  of  the  Chairman. 

Utility  Programs 

Routines  have  been  written  that  perform  various  necessary  functions  with¬ 
out  being  called  explicitly.  These  include,  for  example: 

Text  Editing.  A  text-editing  routine  is  automatically  invoked  whenever 
any  participant  is  asked  to  enter  inputs  at  his  terminal.  This  routine  allows, 
for  example,  deletion  of  the  last  character,  last  line,  or  the  whole  input, 
and  display  of  the  last  line  or  whole  input. 

CRT  Routines.  Several  routines  have  been  developed  for  some  housekeeping 
functions  of  the  CRT  terminals  used.  These  routines  will,  for  example,  clear 
the  participant's  screen  prior  to  commencing  a  lengthy  printout  and,  when  the 
screen  is  full,  pause  for  him  to  read  that  screenful  (thus  avoiding  loss  of 
information  by  "roll-off"  at  the  top  of  the  screen) . 

"Help"  Routines.  When  a  user  gets  into  trouble,  he  merely  types  "help" 

(at  present,  +H) .  Special  routines  are  thus  invoked  to  establish  a  direct 
communications  link  between  the  terminals  of  the  investigator  and  the  respon¬ 
dent  requesting  help.  Upon  termination,  the  routines  provide  for  automatic 
return  to  appropriate  places  in  both  main  programs. 

File  Access  Routines.  These  routines  transfer  text  to  and  from  indexed 
files  under  control  of  higher-level  subroutines. 
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IV.  PROGRAMS  RELEASED  TO  DATE— SPECIFIC  ACCOMPLISHMENTS 


As  mentioned  previously,  improvements  to  the  programs  and  changes  are 
grouped  together  for  debugging,  forming  "releases."  Each  subsequent  release  is 
consecutively  numbered;  we  are  currently  programming  Release  3. 


RELEASE  1 

Release  1  was  the  first  set  of  program  packages  that  could  be  used  to  form 

a  primitive  working  system,  since  it  has  been  superceded,  it  is  described  only 
for  the  project  record; 

questionnaires?  °f  si-^ing  the  answering  of  very  simple 

2.  It  efficiently  provided  fully  asynchronous  operation  only. 

3  single  round  of  questions.  (No  means  existed  for 
Jeapp^aisL?)10  rSSUltS  baCk  t0  the  respondents  for  their  review  and 

,  -1.  Its  sequence  of  operations  was  essentially  like  that  described  in  the 

previous  section  of  this  report. 


RELEASE  2 

Release  2  has  been  completed  and  is  on  file  at  both  the  RAND  and  BBN  PDP-1 
sites  as  a  working  program,  it  differs  from  Release  1  in  the  following  ways: 

1.  It  permits  handling  multiple  rounds  of  the  questionnaire. 

2‘  Tot  ^™"'S,command  capabilities  were  expanded  to  allow  displays 
for  the  whole  inquiry  rather  than  one  topic  at  a  time. 

5.  The  topics  were  organized  on  a  decimal  tree  structure  of  the  form  1.1  ' 
-L  •  i •  z ,  etc. 

4’  in^tSViare  reqUGSted  from  the  respondent  by  startina  each  line 

with  a  herald  character,  ">".  -  m 

5'  t?ied°todmaLPrCtiCa1'  asGr“oriented  conferencing  system,  we  have 
tried  to  make  logging  into  and  use  of  the  conferencing  system  as 
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straight  forward  as  possible.  Fof  easy  reference,  we ; have  prepared  a 
set  of  instructions  on  logging  into  and  use  of  the  conferencing  system. 
Recovery  procedures  in  case  of  failure  are  also  included.1  It  is  hoped 
that,  in  the  normal  course  of  an  inquiry,  these  instructions,  in  addi¬ 
tion  to  the  explicit  instructions  given  by  the  system  itself,  should 
enable  anyone  to  use  the  system  conveniently. 

6.  The  respondent  can,  at  any  time,  exchange  questions  and  messages  with 

the  Chairman  by  requesting  a  link  connection.  '  1 

i 

7.  Text  editing  (control  letter-type) .commands  were  adaptedtd  be  con¬ 
sistent  with  the  convention  used  in  TENEX  (and  TYMSHARE) . 

8.  Samples  oi  text  for  tost  demonstration  purposes  were  simplified  and 

clarified.  1  '  i  •  . 


} 


1 
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V.  CURRENT  PLANS — GENERAL  PROBLEM  AREAS 


'  'teh  °f  U’e  Work  duri"9  the  "ext  aside  from  straightforward  pro¬ 

gramming,  concerns  the  following  four  topics .  modes  (synchronous/asynchronous,, 
1 conferencing  decision  rules,  unburdening  the  chairman,  and  improving  system 
reliability.  These  could  be  regarded  as  problem  areas,  but  since  their  solution 
seems  reasonably  straightforward,  we  are  inclined  to  think  of  wort  on  these 

problems  as  normal  work  topics  to  be  developed  during  the  newt  phases  of  the 
effort.  . 


MQDES 

—  '  I 

We  may  divide  the  interactions  of  the  chairman  and  his  panel  of  respondents 
into  two  timing  categories  or  modes,  synchronous  and  asynchronous.  In  the  syn¬ 
chronous  imode  all  respondents,  for  example,  might  answer  the  same  posed  question 
at  the  same  time.  In  the  asynchronous  mode,  each  respondent  would  answer  the 
question,  but  at'  a  time  of  his  own  choosing. 

I 

;The  asynchronous  mode  lends  itself  more  to  the  questionnaire-answering 
requirement,  whereas  the  synchronous  mode  is  required  in  a  conference  or  debate 
operating  under  controlling  procedures,  such  as  Sober t-s  Sales  of  Order. 

■to  date,  most  of  the  work  on  the  project  has  focused  on  the  asynchronous 
mode,  with  work  now  beginning  on  the  synchronous  mode.  Both  modes  will  be 
required  in  the  final  system,  and  mixed  operation  is  anticipated,  with  increas- 
mg  attention  given  to  the  synchronous  conferencing  phase. 


.CONFERENCING  DECISION  RULES 

i  1  " 

There  are  logical  decision  rules  to  be  developed  to  implement  those  modes 
where  parallel  upward  ccunicatlons  from  the  respondents  is  anticipated,  which 
go  beyond  the  priority  structure  of  Soberf,  Sales  of  order.  For  example, 
Sobert's  Sale,  of  Order  were  formulated  to  handle  basically  binary  decisions, 
a  "yes”  or  "no"  vote  on  a  specific  motion.  This  system  must  also  include  the 


I 
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capability  of  nonbinary  decisions,  such  as  the  group's  estimate  of  the  state  of 

”  3  3  “rtai"  t00hn0l0gy  4“ri"g  y-r,  a  more  difficult  formula- 

o„  We  plan  to  explore  this  subject  in  tore  detail  during  the  next  periods 
Of  this  project. 


unburdening  the  chairman 

is  Pl^d  eVTne  18  all°”°d  *°  talk  ly.  a  heavy  information  burden 

P  aced  on  the  management  team.  The  degree  of  success  of  this  system  will 

epend  to  a  major  degree,  on  success  in  being  able  to  unburden  the  chairman  to 

Z  ZT  lnteraCtl°"  ”OVing  al°"9  9UiCkly  «ajor  attan- 

be  given  to  this  requirement  in  the  next  periods  of  this  project 

including  implementing  the  roles  of  the  Umpire  »d  Editor  separately,  as  describe. 


improving  system  reliability 

To  be  fully  useful,  the  system  must  be  highly  reliable.  Si„ce  „e  are  con¬ 
cerned  with  overall  system  reliability  of  the  entire  conference,  we  must  oper¬ 
ate  at  reliability  levels  higher  than  those  of  the  individual  reliabilities  of 

the  TIPS  and  host)  computers— particularly  better  than  th-,t- 

y  oetter  that  experienced  to  date. 

.  °“  apPr°aCh  60  b°  eXpl0rsi  in  ths  phase  is  that  of  having  the  operat- 

Z  Z7T-  “d  fUeS  reSlde  in  -y  »=  and  the 

BB„  PDP-10  installations.  Boring  the  conference  the  bach-up  computer  will 

interrogate  the  primary  computer,  »hre  you  alive  and  welly  lf  the  answer  is 

no,  |  the  back-up  computer  will  take  over,  communicating  to  the  TIP  and  hosts. 

of  tlxT-  at-  *  tlme’  ThlS  “lU  re,uire  pt,riodlc  £ll°  updates  during  the  course 
inquiry  to  minimise  lost  information  during  the  back-up. 

we  might  handle  the  case  of  the  failure  of  a  TIP  or  local  host,  serving  as 

an  input  tie-in  point  by  having  the  user  call  a  secondary  TIP  and  logging  in 
again. 


In  any  event,  we  plan  to  explore  a 
to  achieve  a  higher  level  of  operational 
experiencing. 


range  of  automatic  back-up  alternatives 
reliability  than  we  are  currently 
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VI.  CURRENT-  PLANS — FUTURE  RELEASES 


,uch  of  the  work  m  the  next  half  year  will  be  adding  new  modules.  This 
i  ,  o  some  extent,  require  revision  of  program  developments  already  written 
We  prefer  this  incremental  developmental  approach  because  it  permits  earlier 
discovery  of  problems  in  the  development  cycle. 

Below  we  describe  improvements  and  additions  that  are  scheduled  for  imple- 
mentation  in  Releases  3  through  5  at  this  time. 


RELEASE  3 

We  are  currently  operating  under  Release  2  while  program  Kelease  3,  our 
nert  scheduled  release,  it  differs  from  Please  2  in  the  following  „ayS! 

1-  A  simple  command  language,  comprising  a  few  action  verb,  ,, 

respondent  more  control  of  his  ^  ?  verbs,  alloivs  the 

it  will  permit  the  respondent  to  skin  ahead^r  h  e.lnquirV-  For  example, 
with  the  background  i/formatL^  b”d 

^spom e 'to '"uTc r "cormands !  h^”9  a'MS‘i  t0  halt  °Utput  to  allow  faster 

b^^cisefby^nespondent9  TAl°  aU°"  *  little  °°""°"  — a  to 

petent  acquaintance  with  the  oA  *  ■ th  resPondent  demonstrates  a  corn- 
matter  of  the  inquiry  he  L  °f  ^  SyStem  and  the 

less  diversion  for  instructions  than  °  thr°Ugh  the  Process  with 

instructions  will  aitonaSal^v  ^ophyte.  These 

Skill,  such  as  counting  erTOs^'^X “  °£  the  USer'S 

‘  =SSr?**-JS.*.Ksr 

Of  leaving  a  message  a^d  Sll  thet  9\™ "  ^  ^ 

inquiry.  e  returned  to  the  continuation  of  the 

6-  S^^^g^f  h“9S  -  -  ia  ted 
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7. 


use  of  the  cursor  add  re  "si  ^"pSu  ity  of  thiT.selt'  inollKiin9  bettor 
the  Chairman  and  the  addition  of  "co„tLl-w»  toTx^Z  ^ 

a"iOTmf“  be  rified  in  prep“- 

program  called  CONVERSATION,  in  the  form  Pbll\ty  needed  later.  A 
the  debate  phase  of  the  questionnaire  answering^aUows  Pr°Ce^re  durin9 
chronous  conversational  capability.  Simple  syn_ 


2. 


RELEASE  4 

include  4  “1U  bUUd  °n  3  “d  add  3  °f  ""  ^Uitios, 

winXpfi”“ZerotuiLaf°LbhSdI^eJsentSlynflff  r°Sp°ndent 

needed  operations  Tt  will  „ ,■  a,  ssentially  all  frequently 

moving  around  hie  guest^aSe 

improved  capability  for  initiating  '•  11  giV0  thc  chai™an  an 

inquiry.  {ln  Release  2  ?  Vari°US  typeS  011(1  Phases  of  the 

up  the  inquiry  by  choice  of  a  nu^rrorbinar^k'^rdV^^h56""1^ 
time-consuming  and  did  not  lend  itself  to  rapid  Vu„c ’^1.^ 

r  “rly  sta9es  °f 

is  partially  overloaded.  Over  the  course  ^  nUmpirC  md'  as  a  r*sult, 

ferentiated  roles  of  the  Editor  and  the  n  P  ^  Writin^  the  dif- 

division  of  roles  and  responsibil^ti  f""  emerge  With  a 

responsibilities'  as  described  earlier. 

domPofSacUo^a  "*?“•■«*  constrained  in  his  free- 

allow  the  respondent  £o bemorf  1^° 7**™*  tho  E>:;ERT  »»»«»  to 

the  inquiry.  This  freedom  of  choiceywillChe""°"dt°£  “5“  piW3a3“  tIlr°u9h 
this  tentative  release.  11  be  continued  and  expanded  in 

Kuias^Ordefii  programs ' V  °f  implc‘"ei*ing  Bert's 

comments  to  see  i/thev  cont  J  e,Ed^tor  "ill  observe  respondents'  typed 
respondent  may^etlh^  **a 

identified,  the  system  miaht  hnn  n  tly) '  0ncG  the  motion  has  been 

hierarchy  if  what-^Jht^er^^hal'  “S^h"3  *1*  Pr0Specifiad 
order,  it  would  be  returned  with  t-u  ’  If  the  motlon  were  out  of 
this  parliamentary  conference  progra./modu^e ' ’  winY^*1  °f 

of  available  motions -perhaps  two  or  th™  It  a.very  Sma11  sot 

later  as  we  feel  our  way  along?"0  ^  ThiS  Ust  wil1  be  extended 
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LPT  ?f/ln°r  lmprOVen,ents  also  be  implemented  at  this  time. 

These  include  improvement  of  the  printed  format  that  is  presented  to 
the  respondent  (the  present  text  format  is  awkward  to  read);  addition 
of  an  automatic  prodding  response  whe  i  the  respondent  takes  too  long 
on  any  single  item;  and  the  addition  of  a  quick  reformatting  capability 

^af  r^TPHn?entS  Wh°Se  numerical  votes  the  extremes  of  the 

panel's  distribution. 

If  performance  of  Release  4  is  as  expected,  then  it  will  be  tested  with  up 
to  about  ten  simultaneously  operated,  geographically  distributed  terminals. 


RELEASE  5 

"  "  "  -  1 

Release  5  will  follow  on,  or  some  of  the  items  may  be  concurrently  developed 
m  Release  4,  and  will  include  the  addition  of  the  following  capabilities; 

lm  provida.recording  means  for  the  panelist's  performance,  such  as 

elapsed  time,  time  to  respond  (adjusted  to  his  measured  typing  speed 
ter^nal  print  rate,  etc),  and  frequency  of  errors  and  SerL^hs'a 
starting  point,  a  magnetic  tape  will  be  written  of  the  entire  inquiry 
with  start  and  stop  times  for  each  interaction.  Playing  back  this 
tape  will  permit  most  measurements  to  be  made  after  the  inquiry  without 
having  to  specify  all  the  test  parameters  in  advance. 

2.  It  will  provide  better  economy  of  storage  use  by  mapping  files  into 
core  only  as  needed  (including  programs  themselves). 

3.  It  will  provide  improved  handling  of  feedback  displays  to  the  respondent¬ 
showing  them  results  of  previous  rounds.  ° ' 

4'  hr  an  ,exl?anded  °f  activity  modules  developed  from  what 

Releien4  “  t0StS  “Uh  the  ton  “mote  respondents  using 

5.  It  will  improve  the  process  that  allows  the  chairman  to  select  sequences 

sequences^  leS  aaslly'  “ith  Particular  emphasis  on  frequently  used 

6.  All  code  will  be  converted  to  reentrant  routines. 

7.  The  control  transfer  program  as  described  in  Section  IV,  under  "Improv- 

^“labiUty'"  in  “hi=h  — t  is  used,  will1  be 

e.  It  will  allow  any  user  to  link  to  any  other,  if  the  chairman  permits. 

9.  Voice  conferencing  capability  will  be  tested. 


